home *** CD-ROM | disk | FTP | other *** search
- Path: xanth!cs.odu.edu!Amiga-Request
- From: Amiga-Request@cs.odu.edu (Amiga Sources/Binaries Moderator)
- Newsgroups: comp.sources.amiga
- Subject: v90i059: uucp 1.03D - unix compatible uucp/mail/news system, Part15/16
- Message-ID: <11298@xanth.cs.odu.edu>
- Date: 4 Feb 90 02:43:55 GMT
- Sender: tadguy@cs.odu.edu
- Reply-To: overload!dillon (Matt Dillon)
- Lines: 1350
- Approved: tadguy@cs.odu.edu (Tad Guy)
- X-Mail-Submissions-To: Amiga@cs.odu.edu
-
- Submitted-by: overload!dillon (Matt Dillon)
- Posting-number: Volume 90, Issue 059
- Archive-name: unix/uucp-1.03d/part15
-
- #!/bin/sh
- # This is a shell archive. Remove anything before this line, then unpack
- # it by saving it into a file and typing "sh file". To overwrite existing
- # files, type "sh file -c". You can also feed this as standard input via
- # unshar, or by typing "sh <file", e.g.. If this archive is complete, you
- # will see the following message at the end:
- # "End of archive 15 (of 16)."
- # Contents: man/Standards.aa
- # Wrapped by tadguy@xanth on Sat Feb 3 20:51:25 1990
- PATH=/bin:/usr/bin:/usr/ucb ; export PATH
- if test -f 'man/Standards.aa' -a "${1}" != "-c" ; then
- echo shar: Will not clobber existing file \"'man/Standards.aa'\"
- else
- echo shar: Extracting \"'man/Standards.aa'\" \(48305 characters\)
- sed "s/^X//" >'man/Standards.aa' <<'END_OF_FILE'
- X
- X Standard for Interchange of USENET Messages
- X
- X Mark R. Horton
- X
- X
- X
- X
- X 1. Introduction
- Introduction
- Introduction
- Introduction
- X
- X This document defines the standard format for interchange
- X of Network News articles among USENET sites. It describes
- X the format for articles themselves, and gives partial
- X standards for transmission of news. The news transmission
- X is not entirely standardized in order to give a good deal
- X of flexibility to the individual hosts to choose
- X transmission hardware and software, whether to batch news,
- X and so on.
- X
- X There are five sections to this document. Section two
- X section defines the format. Section three defines the
- X valid control messages. Section four specifies some valid
- X transmission methods. Section five describes the overall
- X news propagation algorithm.
- X
- X
- X 2. Article Format
- Article Format
- Article Format
- Article Format
- X
- X The primary consideration in choosing an article format is
- X that it fit in with existing tools as well as possible.
- X Existing tools include both implementations of mail and
- X news. (The notesfiles system from the University of
- __________
- X Illinois is considered a news implementation.) A standard
- X format for mail messages has existed for many years on the
- X ARPANET, and this format meets most of the needs of
- X USENET. Since the ARPANET format is extensible,
- X extensions to meet the additional needs of USENET are
- X easily made within the ARPANET standard. Therefore, the
- X rule is adopted that all USENET news articles must be
- X formatted as valid ARPANET mail messages, according to the
- X ARPANET standard RFC 822. This standard is more
- X restrictive than the ARPANET standard, placing additional
- X requirements on each article and forbidding use of certain
- X ARPANET features. However, it should always be possible
- X to use a tool expecting an ARPANET message to process a
- X news article. In any situation where this standard
- X conflicts with the ARPANET standard, RFC 822 should be
- X considered correct and this standard in error.
- X
- X An example message is included to illustrate the fields.
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 2 -
- X
- X
- X
- X Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
- X Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
- X Path: cbosgd!mhuxj!mhuxt!eagle!jerry
- X From: jerry@eagle.uucp (Jerry Schwarz)
- X Newsgroups: net.general
- X Subject: Usenet Etiquette -- Please Read
- X Message-ID: <642@eagle.UUCP>
- X Date: Friday, 19-Nov-82 16:14:55 EST
- X Followup-To: net.news
- X Expires: Saturday, 1-Jan-83 00:00:00 EST
- X Date-Received: Friday, 19-Nov-82 16:59:30 EST
- X Organization: Bell Labs, Murray Hill
- X
- X The body of the article comes here, after a blank line.
- X
- X Here is an example of a message in the old format (before
- X the existence of this standard). It is recommended that
- X implementations also accept articles in this format to
- X ease upward conversion.
- X
- X From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
- X Newsgroups: net.general
- X Title: Usenet Etiquette -- Please Read
- X Article-I.D.: eagle.642
- X Posted: Fri Nov 19 16:14:55 1982
- X Received: Fri Nov 19 16:59:30 1982
- X Expires: Mon Jan 1 00:00:00 1990
- X
- X The body of the article comes here, after a blank line.
- X
- X Some news systems transmit news in the ``A'' format, which
- X looks like this:
- X
- X Aeagle.642
- X net.general
- X cbosgd!mhuxj!mhuxt!eagle!jerry
- X Fri Nov 19 16:14:55 1982
- X Usenet Etiquette - Please Read
- X The body of the article comes here, with no blank line.
- X
- X An article consists of several header lines, followed by a
- X blank line, followed by the body of the message. The
- X header lines consist of a keyword, a colon, a blank, and
- X some additional information. This is a subset of the
- X ARPANET standard, simplified to allow simpler software to
- X handle it. The ``from'' line may optionally include a
- X full name, in the format above, or use the ARPANET angle
- X bracket syntax. To keep the implementations simple, other
- X formats (for example, with part of the machine address
- X after the close parenthesis) are not allowed. The ARPANET
- X convention of continuation header lines (beginning with a
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 3 -
- X
- X
- X
- X blank or tab) is allowed.
- X
- X Certain headers are required, certain headers are
- X optional. Any unrecognized headers are allowed, and will
- X be passed through unchanged. The required headers are
- X Relay-Version, Posting-Version, From, Date, Newsgroups,
- X Subject, Message-ID, Path. The optional headers are
- X Followup-To, Date-Received, Expires, Reply-To, Sender,
- X References, Control, Distribution, Organization.
- X
- X 2.1 Required Headers
- Required Headers
- Required Headers
- Required Headers
- X
- X 2.1.1 Relay-Version This header line shows the version
- _____________
- X of the program responsible for the transmission of this
- X article over the immediate link, that is, the program that
- X is relaying the article from the next site. For example,
- X suppose site A sends an article to site B, and site B
- X forwards the article to site C. The message being
- X transmitted from A to B would have a Relay-Version header
- X identifying the program running on A, and the message
- X transmitted from B to C would identify the program running
- X on B. This header can be used to interpret older headers
- X in an upward compatible way. Relay-Version must always be
- X the first in a message; thus, all articles meeting this
- X standard will begin with an upper case ``R''. No other
- X restrictions are placed on the order of header lines.
- X
- X The line contains two fields, separated by semicolons.
- X The fields are the version and the full domain name of the
- X site. The version should identify the system program used
- X (e.g., ``B'') as well as a version number and version
- X date. For example, the header line might contain
- X
- X Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
- X
- X This header should not be passed on to additional sites.
- X A relay program, when passing an article on, should
- X include only its own Relay-Version, not the Relay-Version
- X of some other site. (For upward compatibility with older
- X software, if a Relay-Version is found in a header which is
- X not the first line, it should be assumed to be moved by an
- X older version of news and deleted.)
- X
- X 2.1.2 Posting-Version This header identifies the
- _______________
- X software responsible for entering this message into the
- X network. It has the same format as Relay-Version. It
- X will normally identify the same site as the Message-ID,
- X unless the posting site is serving as a gateway for a
- X message that already contains a message ID generated by
- X mail. (While it is permissible for a gateway to use an
- X externally generated message ID, the message ID should be
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 4 -
- X
- X
- X
- X checked to ensure it conforms to this standard and to RFC
- X 822.)
- X
- X 2.1.3 From The From line contains the electronic mailing
- ____
- X address of the person who sent the message, in the ARPA
- X internet syntax. It may optionally also contain the full
- X name of the person, in parentheses, after the electronic
- X address. The electronic address is the same as the entity
- X responsible for originating the article, unless the Sender
- X header is present, in which case the From header might not
- X be verified. Note that in all site and domain names,
- X upper and lower case are considered the same, thus
- X mark@cbosgd.UUCP, mark@cbosgd.uucp, and mark@CBosgD.UUcp
- X are all equivalent. User names may or may not be case
- X sensitive, for example, Billy@cbosgd.UUCP might be
- X different from BillY@cbosgd.UUCP. Programs should avoid
- X changing the case of electronic addresses when forwarding
- X news or mail.
- X
- X RFC 822 specifies that all text in parentheses is to be
- X interpreted as a comment. It is common in ARPANET mail to
- X place the full name of the user in a comment at the end of
- X the From line. This standard specifies a more rigid
- X syntax. The full name is not considered a comment, but an
- X optional part of the header line. Either the full name is
- X omitted, or it appears in parentheses after the electronic
- X address of the person posting the article, or it appears
- X before an electronic address enclosed in angle brackets.
- X Thus, the three permissible forms are:
- X
- X From: mark@cbosgd.UUCP
- X From: mark@cbosgd.UUCP (Mark Horton)
- X From: Mark Horton <mark@cbosgd.UUCP>
- X
- X Full names may contain any printing ASCII characters from
- X space through tilde, with the exceptions that they may not
- X contain parentheses ``('' or ``)'', or angle brackets
- X ``<'' or ``>''. Additional restrictions may be placed on
- X full names by the mail standard, in particular, the
- X characters comma ``,'', colon ``:'', and semicolon ``;''
- X are inadvisable in full names.
- X
- X 2.1.4 Date The Date line (formerly ``Posted'') is the
- ____
- X date, in a format that must be acceptable both to the
- X ARPANET and to the getdate routine, that the article was
- X originally posted to the network. This date remains
- X unchanged as the article is propagated throughout the
- X network. One format that is acceptable to both is
- X
- X Weekday, DD-Mon-YY HH:MM:SS TIMEZONE
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 5 -
- X
- X
- X
- X Several examples of valid dates appear in the sample
- X article above. Note in particular that ctime format:
- X
- X Wdy Mon DD HH:MM:SS YYYY
- X
- X is not acceptable because it is not a valid ARPANET date.
- ___
- X However, since older software still generates this format,
- X news implementations are encouraged to accept this format
- X and translate it into an acceptable format.
- X
- X The contents of the TIMEZONE field is currently subject to
- X revision. Eventually, we hope to accept all possible
- X worldwide time zone abbreviations, including the usual
- X American zones (PST, PDT, MST, MDT, CST, CDT, EST, EDT),
- X the other North American zones (Bering through
- X Newfoundland), European zones, Australian zones, and so
- X on. Lacking a complete list at present (and unsure if an
- X unambiguous list exists), authors of software are
- X encouraged to keep this code flexible, and in particular
- X not to assume that time zone names are exactly three
- X letters long. Implementations are free to edit this
- X field, keeping the time the same, but changing the time
- X zone (with an appropriate adjustment to the local time
- X shown) to a known time zone.
- X
- X 2.1.5 Newsgroups The Newsgroups line specifies which
- __________
- X newsgroup or newsgroups the article belongs in. Multiple
- X newsgroups may be specified, separated by a comma.
- X Newsgroups specified must all be the names of existing
- X newsgroups, as no new newsgroups will be created by simply
- X posting to them.
- X
- X Wildcards (e.g., the word ``all'') are never allowed in a
- X Newsgroups line. For example, a newsgroup ``net.all'' is
- X illegal, although a newsgroup name ``net.sport.football''
- X is permitted.
- X
- X If an article is received with a Newsgroups line listing
- X some valid newsgroups and some invalid newsgroups, a site
- X should not remove invalid newsgroups from the list.
- X Instead, the invalid newsgroups should be ignored. For
- X example, suppose site A subscribes to the classes
- X ``btl.all'' and ``net.all'', and exchanges news articles
- X with site B, which subscribes to ``net.all'' but not
- X ``btl.all''. Suppose A receives an article with
- X ``Newsgroups: net.micro,btl.general''. This article is
- X passed on to B because B receives net.micro, but B does
- X not receive btl.general. A must leave the Newsgroup line
- X unchanged. If it were to remove ``btl.general'', the
- X edited header could eventually reenter the ``btl.all''
- X class, resulting in an article that is not shown to users
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 6 -
- X
- X
- X
- X subscribing to ``btl.general''. Also, followups from
- X outside ``btl.all'' would not be shown to such users.
- X
- X 2.1.6 Subject The Subject line (formerly ``Title'')
- _______
- X tells what the article is about. It should be suggestive
- X enough of the contents of the article to enable a reader
- X to make a decision whether to read the article based on
- X the subject alone. If the article is submitted in
- X response to another article (e.g., is a ``followup'') the
- X default subject should begin with the four characters
- X ``Re: '' and the References line is required. (The user
- X might wish to edit the subject of the followup, but the
- X default should begin with ``Re: ''.)
- X
- X 2.1.7 Message-ID The Message-ID line gives the article a
- __________
- X unique identifier. The same message ID may not be reused
- X during the lifetime of any article with the same message
- X ID. (It is recommended that no message ID be reused for
- X at least two years.) Message ID's have the syntax
- X
- X "<" "string not containing blank or >" ">"
- X
- X In order to conform to RFC 822, the Message-ID must have
- X the format
- X
- X "<" "unique" "@" "full domain name" ">"
- X
- X where ``full domain name'' is the full name of the host at
- X which the article entered the network, including a domain
- X that host is in, and unique is any string of printing
- X ASCII characters, not including "<", ">", or "@". For
- X example, the "unique" part could be an integer
- X representing a sequence number for articles submitted to
- X the network, or a short string derived from the date and
- X time the article was created. For example, valid message
- X ID for an article submitted from site ucbvax in domain
- X Berkeley.ARPA would be "<4123@ucbvax.Berkeley.ARPA>".
- X Programmers are urged not to make assumptions about the
- X content of message ID fields from other hosts, but to
- X treat them as unknown character strings. It is not safe,
- X for example, to assume that a message ID will be under 14
- X characters, nor that it is unique in the first 14
- X characters.
- X
- X The angle brackets are considered part of the message ID.
- X Thus, in references to the message ID, such as the
- X ihave/sendme and cancel control messages, the angle
- X brackets are included. White space characters (e.g.,
- X blank and tab) are not allowed in a message ID. All
- X characters between the angle brackets must be printing
- X ASCII characters.
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 7 -
- X
- X
- X
- X 2.1.8 Path This line shows the path the article took to
- ____
- X reach the current system. When a system forwards the
- X message, it should add its own name to the list of systems
- X in the Path line. The names may be separated by any
- X punctuation character or characters, thus
- X ``cbosgd!mhuxj!mhuxt'', ``cbosgd, mhuxj, mhuxt'', and
- X ``@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp'' and even
- X ``teklabs, zehntel, sri-unix@cca!decvax'' are valid
- X entries. (The latter path indicates a message that passed
- X through decvax, cca, sri-unix, zehntel, and teklabs, in
- X that order.) Additional names should be added from the
- X left, for example, the most recently added name in the
- X third example was ``teklabs''. Letters, digits, periods
- X and hyphens are considered part of site names; other
- X punctuation, including blanks, are considered separators.
- X
- X Normally, the rightmost name will be the name of the
- X originating system. However, it is also permissible to
- X include an extra entry on the right, which is the name of
- X the sender. This is for upward compatibility with older
- X system.
- X
- X The Path line is not used for replies, and should not be
- X taken as a mailing address. It is intended to show the
- X route the message travelled to reach the local site.
- X There are several uses for this information. One is to
- X monitor USENET routing for performance reasons. Another
- X is to establish a path to reach new sites. Perhaps the
- X most important is to cut down on redundant USENET traffic
- X by failing to forward a message to a site that is known to
- X have already received it. In particular, when site A
- X sends an article to site B, the Path line includes ``A'',
- X so that site B will not immediately send the article back
- X to site A. The site name each site uses to identify
- X itself should be the same as the name by which its
- X neighbors know it, in order to make this optimization
- X possible.
- X
- X A site adds its own name to the front of a path when it
- X receives a message from another site. Thus, if a message
- X with path A!X!Y!Z is passed from site A to site B, B will
- X add its own name to the path when it receives the message
- X from A, e.g., B!A!X!Y!Z. If B then passes the message on
- X to C, the message sent to C will contain the path
- X B!A!X!Y!Z, and when C receives it, C will change it to
- X C!B!A!X!Y!Z.
- X
- X Special upward compatibility note: Since the From, Sender,
- X and Reply-To lines are in internet format, and since many
- X USENET sites do not yet have mailers capable of
- X understanding internet format, it would break the reply
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 8 -
- X
- X
- X
- X capability to completely sever the connection between the
- X Path header and the reply function. Thus, sites are
- X required to continue to keep the Path line in a working
- X reply format as much as possible, until January 1, 1984.
- X It is recognized that the path is not always a valid reply
- X string in older implementations, and no requirement to fix
- X this problem is placed on implementations. However, the
- X existing convention of placing the site name and an ``!''
- X at the front of the path, and of starting the path with
- X the site name, an ``!'', and the user name, should be
- X maintained at least until 1984.
- X
- X 2.2 Optional Headers
- Optional Headers
- Optional Headers
- Optional Headers
- X
- X 2.2.1 Reply-To This line has the same format as From.
- ________
- X If present, mailed replies to the author should be sent to
- X the name given here. Otherwise, replies are mailed to the
- X name on the From line. (This does not prevent additional
- X copies from being sent to recipients named by the replier,
- X or on To or Cc lines.) The full name may be optionally
- X given, in parentheses, as in the From line.
- X
- X 2.2.2 Sender This field is present only if the submitter
- ______
- X manually enters a From line. It is intended to record the
- X entity responsible for submitting the article to the
- X network, and should be verified by the software at the
- X submitting site.
- X
- X For example, if John Smith is visiting CCA and wishes to
- X post an article to the network, using friend Sarah Jones
- X account, the message might read
- X
- X From: smith@ucbvax.uucp (John Smith)
- X Sender: jones@cca.arpa (Sarah Jones)
- X
- X If a gateway program enters a mail message into the
- X network at site sri-unix, the lines might read
- X
- X From: John.Doe@CMU-CS-A.ARPA
- X Sender: network@sri-unix.ARPA
- X
- X The primary purpose of this field is to be able to track
- X down articles to determine how they were entered into the
- X network. The full name may be optionally given, in
- X parentheses, as in the From line.
- X
- X 2.2.3 Followup-To This line has the same format as
- ___________
- X Newsgroups. If present, follow-up articles are to be
- X posted to the newsgroup(s) listed here. If this line is
- X not present, followups are posted to the newsgroup(s)
- X listed in the Newsgroups line, except that followups to
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 9 -
- X
- X
- X
- X ``net.general'' should instead go to ``net.followup''.
- X
- X 2.2.4 Date-Received This line (formerly ``Received'') is
- _____________
- X in a legal USENET date format. It records the date and
- X time that the article was first received on the local
- X system. If this line is present in an article being
- X transmitted from one host to another, the receiving host
- X should ignore it and replace it with the current date.
- X Since this field is intended for local use only, no site
- X is required to support it. However, no site should pass
- X this field on to another site unchanged.
- X
- X 2.2.5 Expires This line, if present, is in a legal
- _______
- X USENET date format. It specifies a suggested expiration
- X date for the article. If not present, the local default
- X expiration date is used.
- X
- X This field is intended to be used to clean up articles
- X with a limited usefulness, or to keep important articles
- X around for longer than usual. For example, a message
- X announcing an upcoming seminar could have an expiration
- X date the day after the seminar, since the message is not
- X useful after the seminar is over. Since local sites have
- X local policies for expiration of news (depending on
- X available disk space, for instance), users are discouraged
- X from providing expiration dates for articles unless there
- X is a natural expiration date associated with the topic.
- X System software should almost never provide a default
- X Expires line. Leave it out and allow local policies to be
- X used unless there is a good reason not to.
- X
- X 2.2.6 References This field lists the message ID's of
- __________
- X any articles prompting the submission of this article. It
- X is required for all follow-up articles, and forbidden when
- X a new subject is raised. Implementations should provide a
- X follow-up command, which allows a user to post a follow-up
- X article. This command should generate a Subject line
- X which is the same as the original article, except that if
- X the original subject does not begin with ``Re: '' or ``re:
- X '', the four characters ``Re: '' are inserted before the
- X subject. If there is no References line on the original
- X header, the References line should contain the message ID
- X of the original article (including the angle brackets).
- X If the original article does have a References line, the
- X followup article should have a References line containing
- X the text of the original References line, a blank, and the
- X message ID of the original article.
- X
- X The purpose of the References header is to allow articles
- X to be grouped into conversations by the user interface
- X program. This allows conversations within a newsgroup to
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 10 -
- X
- X
- X
- X be kept together, and potentially users might shut off
- X entire conversations without unsubscribing to a newsgroup.
- X User interfaces may not make use of this header, but all
- X automatically generated followups should generate the
- X References line for the benefit of systems that do use it,
- X and manually generated followups (e.g. typed in well after
- X the original article has been printed by the machine)
- X should be encouraged to include them as well.
- X
- X 2.2.7 Control If an article contains a Control line, the
- _______
- X article is a control message. Control messages are used
- X for communication among USENET host machines, not to be
- X read by users. Control messages are distributed by the
- X same newsgroup mechanism as ordinary messages. The body
- X of the Control header line is the message to the host.
- X
- X For upward compatibility, messages that match the
- X newsgroup pattern ``all.all.ctl'' should also be
- X interpreted as control messages. If no Control: header is
- X present on such messages, the subject is used as the
- X control message. However, messages on newsgroups matching
- X this pattern do not conform to this standard.
- X
- X 2.2.8 Distribution This line is used to alter the
- ____________
- X distribution scope of the message. It has the same format
- X as the Newsgroups line. User subscriptions are still
- X controlled by Newsgroups, but the message is sent to all
- X systems subscribing to the newsgroups on the Distribution
- X line instead of the Newsgroups line. Thus, a car for sale
- X in New Jersey might have headers including
- X
- X Newsgroups: net.auto,net.wanted
- X Distribution: nj.all
- X
- X so that it would only go to persons subscribing to
- X net.auto or net.wanted within New Jersey. The intent of
- X this header is to further restrict the distribution of a
- X newsgroup, not to increase it. A local newsgroup, such as
- X nj.crazy-eddie, will probably not be propagated by sites
- X outside New Jersey that do not show such a newsgroup as
- X valid. Wildcards in newsgroup names in the Distribution
- X line are allowed. Followup articles should default to the
- X same Distribution line as the original article, but the
- X user can change it to a more limited one, or escalate the
- X distribution if it was originally restricted and a more
- X widely distributed reply is appropriate.
- X
- X 2.2.9 Organization The text of this line is a short
- ____________
- X phrase describing the organization to which the sender
- X belongs, or to which the machine belongs. The intent of
- X this line is to help identify the person posting the
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 11 -
- X
- X
- X
- X message, since site names are often cryptic enough to make
- X it hard to recognize the organization by the electronic
- X address.
- X
- X
- X 3. Control Messages
- Control Messages
- Control Messages
- Control Messages
- X
- X This section lists the control messages currently defined.
- X The body of the Control header is the control message.
- X Messages are a sequence of zero or more words, separated
- X by white space (blanks or tabs). The first word is the
- X name of the control message, remaining words are
- X parameters to the message. The remainder of the header
- X and the body of the message are also potential parameters;
- X for example, the From line might suggest an address to
- X which a response is to be mailed.
- X
- X Implementors and administrators may choose to allow
- X control messages to be automatically carried out, or to
- X queue them for manual processing. However, manually
- X processed messages should be dealt with promptly.
- X
- X 3.1 Cancel
- Cancel
- Cancel
- Cancel
- X
- X cancel <message ID>
- X
- X If an article with the given message ID is present on the
- X local system, the article is cancelled. This mechanism
- X allows a user to cancel an article after the article has
- X been distributed over the network.
- X
- X Only the author of the article or the local super user is
- X allowed to use this message. The verified sender of a
- X message is the Sender line, or if no Sender line is
- X present, the From line. The verified sender of the cancel
- X message must be the same as either the Sender or From
- X field of the original message. A verified sender in the
- X cancel message is allowed to match an unverified From in
- X the original message.
- X
- X 3.2 Ihave/Sendme
- Ihave/Sendme
- Ihave/Sendme
- Ihave/Sendme
- X
- X ihave <message ID list> <remotesys>
- X sendme <message ID list> <remotesys>
- X
- X This message is part of the ``ihave/sendme'' protocol,
- X which allows one site (say ``A'') to tell another site
- X (``B'') that a particular message has been received on A.
- X Suppose that site A receives article ``ucbvax.1234'', and
- X wishes to transmit the article to site B. A sends the
- X control message ``ihave ucbvax.1234 A'' to site B (by
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 12 -
- X
- X
- X
- X posting it to newsgroup ``to.B''). B responds with the
- X control message ``sendme ucbvax.1234 B'' (on newsgroup
- X to.A) if it has not already received the article. Upon
- X receiving the Sendme message, A sends the article to B.
- X
- X This protocol can be used to cut down on redundant traffic
- X between sites. It is optional and should be used only if
- X the particular situation makes it worthwhile. Frequently,
- X the outcome is that, since most original messages are
- X short, and since there is a high overhead to start sending
- X a new message with UUCP, it costs as much to send the
- X Ihave as it would cost to send the article itself.
- X
- X One possible solution to this overhead problem is to batch
- X requests. Several message ID's may be announced or
- X requested in one message. If no message ID's are listed
- X in the control message, the body of the message should be
- X scanned for message ID's, one per line.
- X
- X 3.3 Newgroup
- Newgroup
- Newgroup
- Newgroup
- X
- X newgroup <groupname>
- X
- X This control message creates a new newsgroup with the name
- X given. Since no articles may be posted or forwarded until
- X a newsgroup is created, this message is required before a
- X newsgroup can be used. The body of the message is
- X expected to be a short paragraph describing the intended
- X use of the newsgroup.
- X
- X 3.4 Rmgroup
- Rmgroup
- Rmgroup
- Rmgroup
- X
- X rmgroup <groupname>
- X
- X This message removes a newsgroup with the given name.
- X Since the newsgroup is removed from every site on the
- X network, this command should be used carefully by a
- X responsible administrator.
- X
- X 3.5 Sendsys
- Sendsys
- Sendsys
- Sendsys
- X
- X sendsys (no arguments)
- X
- X The ``sys'' file, listing all neighbors and which
- X newsgroups are sent to each neighbor, will be mailed to
- X the author of the control message (Reply-to, if present,
- X otherwise From). This information is considered public
- X information, and it is a requirement of membership in
- X USENET that this information be provided on request,
- X either automatically in response to this control message,
- X or manually, by mailing the requested information to the
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 13 -
- X
- X
- X
- X author of the message. This information is used to keep
- X the map of USENET up to date, and to determine where
- X netnews is sent.
- X
- X The format of the file mailed back to the author should be
- X the same as that of the ``sys'' file. This format has one
- X line per neighboring site (plus one line for the local
- X site), containing four colon separated fields. The first
- X field has the site name of the neighbor, the second field
- X has a newsgroup pattern describing the newsgroups sent to
- X the neighbor. The third and fourth fields are not defined
- X by this standard. A sample response:
- X
- X From cbosgd!mark Sun Mar 27 20:39:37 1983
- X Subject: response to your sendsys request
- X To: mark@cbosgd.UUCP
- X
- X Responding-System: cbosgd.UUCP
- X cbosgd:osg,cb,btl,bell,net,fa,to,test
- X ucbvax:net,fa,to.ucbvax:L:
- X cbosg:net,fa,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
- X cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
- X sescent:net,fa,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
- X npois:net,fa,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
- X mhuxi:net,fa,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
- X
- X 3.6 Senduuname
- Senduuname
- Senduuname
- Senduuname
- X
- X senduuname (no arguments)
- X
- X The ``uuname'' program is run, and the output is mailed to
- X the author of the control message (Reply-to, if present,
- X otherwise From). This program lists all uucp neighbors of
- X the local site. This information is used to make maps of
- X the UUCP network. The sys file is not the same as the
- ___
- X UUCP L.sys file. The L.sys file should never be
- _____
- X transmitted to another party without the consent of the
- X sites whose passwords are listed therein.
- X
- X It is optional for a site to provide this information.
- X Some reply should be made to the author of the control
- X message, so that a transmission error won't be blamed. It
- X is also permissible for a site to run the uuname program
- X (or in some other way determine the uucp neighbors) and
- X edit the output, either automatically or manually, before
- X mailing the reply back to the author. The file should
- X contain one site per line, beginning with the uucp site
- X name. Additional information may be included, separated
- X from the site name by a blank or tab. The phone number or
- X password for the site should NOT be included, as the reply
- X is considered to be in the public domain. (The uuname
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 14 -
- X
- X
- X
- X program will send only the site name and not the entire
- X contents of the L.sys file, thus, phone numbers and
- X passwords are not transmitted.)
- X
- X The purpose of this message is to generate and maintain
- X UUCP mail routing maps. Thus, connections over which mail
- X can be sent using the site!user syntax should be included,
- X regardless of whether the link is actually a UUCP link at
- X the physical level. If a mail router should use it, it
- X should be included. Since all information sent in
- X response to this message is optional, sites are free to
- X edit the list, deleting secret or private links they do
- X not wish to publicise.
- X
- X 3.7 Version
- Version
- Version
- Version
- X
- X version (no arguments)
- X
- X The name and version of the software running on the local
- X system is to be mailed back to the author of the article
- X (Reply-to if present, otherwise From).
- X
- X
- X 4. Transmission Methods
- Transmission Methods
- Transmission Methods
- Transmission Methods
- X
- X USENET is not a physical network, but rather a logical
- X network resting on top of several existing physical
- X networks. These networks include, but are not limited to,
- X UUCP, the ARPANET, an Ethernet, the BLICN network, an NSC
- X Hyperchannel, and a Berknet. What is important is that
- X two neighboring systems on USENET have some method to get
- X a new article, in the format listed here, from one system
- X to the other, and once on the receiving system, processed
- X by the netnews software on that system. (On UNIX systems,
- X this usually means the ``rnews'' program being run with
- X the article on the standard input.)
- X
- X It is not a requirement that USENET sites have mail
- X systems capable of understanding the ARPA Internet mail
- X syntax, but it is strongly recommended. Since From,
- X Reply-To, and Sender lines use the Internet syntax,
- X replies will be difficult or impossible without an
- X internet mailer. A site without an internet mailer can
- X attempt to use the Path header line for replies, but this
- X field is not guaranteed to be a working path for replies.
- X In any event, any site generating or forwarding news
- X messages must have an internet address that allows them to
- X receive mail from sites with internet mailers, and they
- X must include their internet address on their From line.
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 15 -
- X
- X
- X
- X 4.1 Remote Execution
- Remote Execution
- Remote Execution
- Remote Execution
- X
- X Some networks permit direct remote command execution. On
- X these networks, news may be forwarded by spooling the
- X rnews command with the article on the standard input. For
- X example, if the remote system is called ``remote'', news
- X would be sent over a UUCP link with the command ``uux -
- X remote!rnews'', and on a Berknet, ``net -mremote rnews''.
- X It is important that the article be sent via a reliable
- X mechansim, normally involving the possibility of spooling,
- X rather than direct real-time remote execution. This is
- X because, if the remote system is down, a direct execution
- X command will fail, and the article will never be
- X delivered. If the article is spooled, it will eventually
- X be delivered when both systems are up.
- X
- X 4.2 Transfer by Mail
- Transfer by Mail
- Transfer by Mail
- Transfer by Mail
- X
- X On some systems, direct remote spooled execution is not
- X possible. However, most systems support electronic mail,
- X and a news article can be sent as mail. One approach is
- X to send a mail message which is identical to the news
- X message: the mail headers are the news headers, and the
- X mail body is the news body. By convention, this mail is
- X sent to the user ``newsmail'' on the remote machine.
- X
- X One problem with this method is that it may not be
- X possible to convince the mail system that the From line of
- X the message is valid, since the mail message was generated
- X by a program on a system different from the source of the
- X news article. Another problem is that error messages
- X caused by the mail transmission would be sent to the
- X originator of the news article, who has no control over
- X news transmission between two cooperating hosts and does
- X not know who to contact. Transmission error messages
- X should be directed to a responsible contact person on the
- X sending machine.
- X
- X A solution to this problem is to encapsulate the news
- X article into a mail message, such that the entire article
- X (headers and body) are part of the body of the mail
- X message. The convention here is that such mail is sent to
- X user ``rnews'' on the remote system. A mail message body
- X is generated by prepending the letter ``N'' to each line
- X of the news article, and then attaching whatever mail
- X headers are convenient to generate. The N's are attached
- X to prevent any special lines in the news article from
- X interfering with mail transmission, and to prevent any
- X extra lines inserted by the mailer (headers, blank lines,
- X etc.) from becoming part of the news article. A program
- X on the receiving machine receives mail to ``rnews'',
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 16 -
- X
- X
- X
- X extracting the article itself and invoking the ``rnews''
- X program. An example in this format might look like this:
- X
- X Date: Monday, 3-Jan-83 08:33:47 MST
- X From: news@cbosgd.UUCP
- X Subject: network news article
- X To: rnews@npois.UUCP
- X
- X NRelay-Version: B 2.10 2/13/83 cbosgd.UUCP
- X NPosting-Version: B 2.9 6/21/82 sask.UUCP
- X NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
- X NFrom: derek@sask.UUCP (Derek Andrew)
- X NNewsgroups: net.test
- X NSubject: necessary test
- X NMessage-ID: <176@sask.UUCP>
- X NDate: Monday, 3-Jan-83 00:59:15 MST
- X N
- X NThis really is a test. If anyone out there more than 6
- X Nhops away would kindly confirm this note I would
- X Nappreciate it. We suspect that our news postings
- X Nare not getting out into the world.
- X N
- X
- X
- X Using mail solves the spooling problem, since mail must
- X always be spooled if the destination host is down.
- X However, it adds more overhead to the transmission process
- X (to encapsulate and extract the article) and makes it
- X harder for software to give different priorities to news
- X and mail.
- X
- X 4.3 Batching
- Batching
- Batching
- Batching
- X
- X Since news articles are usually short, and since a large
- X number of messages are often sent between two sites in a
- X day, it may make sense to batch news articles. Several
- X articles can be combined into one large article, using
- X conventions agreed upon in advance by the two sites. One
- X such batching scheme is described here; its use is still
- X considered experimental.
- X
- X News articles are combined into a script, separated by a
- X header of the form:
- X
- X ##! rnews 1234
- X
- X where 1234 is the length, in bytes, of the article. Each
- X such line is followed by an article containing the given
- X number of bytes. (The newline at the end of each line of
- X the article is counted as one byte, for purposes of this
- X count, even if it is stored as CRLF.) For example, a batch
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 17 -
- X
- X
- X
- X of articles might look like this:
- X
- X #! rnews 374
- X Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
- X Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
- X Path: cbosgd!mhuxj!mhuxt!eagle!jerry
- X From: jerry@eagle.uucp (Jerry Schwarz)
- X Newsgroups: net.general
- X Subject: Usenet Etiquette -- Please Read
- X Message-ID: <642@eagle.UUCP>
- X Date: Friday, 19-Nov-82 16:14:55 EST
- X
- X Here is an important message about USENET Etiquette.
- X #! rnews 378
- X Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
- X Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
- X Path: cbosgd!mhuxj!mhuxt!eagle!jerry
- X From: jerry@eagle.uucp (Jerry Schwarz)
- X Newsgroups: net.followup
- X Subject: Notes on Etiquette article
- X Message-ID: <643@eagle.UUCP>
- X Date: Friday, 19-Nov-82 17:24:12 EST
- X
- X There was something I forgot to mention in the last message.
- X
- X Batched news is recognized because the first character in
- X the message is ``#''. The message is then passed to the
- X unbatcher for interpretation.
- X
- X
- X 5. The News Propagation Algorithm
- The News Propagation Algorithm
- The News Propagation Algorithm
- The News Propagation Algorithm
- X
- X This section describes the overall scheme of USENET and
- X the algorithm followed by sites in propagating news to the
- X entire network. Since all sites are affected by
- X incorrectly formatted articles and by propagation errors,
- X it is important for the method to be standardized.
- X
- X USENET is a directed graph. Each node in the graph is a
- X host computer, each arc in the graph is a transmission
- X path from one host to another host. Each arc is labelled
- X with a newsgroup pattern, specifying which newsgroup
- X classes are forwarded along that link. Most arcs are
- X bidirectional, that is, if site A sends a class of
- X newsgroups to site B, then site B usually sends the same
- X class of newsgroups to site A. This bidirectionality is
- X not, however, required.
- X
- X USENET is made up of many subnetworks. Each subnet has a
- X name, such as ``net'' or ``btl''. The special subnet
- X ``net'' is defined to be USENET, although the union of all
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 18 -
- X
- X
- X
- X subnets may be a superset of USENET (because of sites that
- X get local newsgroup classes but do not get net.all). Each
- X subnet is a connected graph, that is, a path exists from
- X every node to every other node in the subnet. In
- X addition, the entire graph is (theoretically) connected.
- X (In practice, some political considerations have caused
- X some sites to be unable to post articles reaching the rest
- X of the network.)
- X
- X An article is posted on one machine to a list of
- X newsgroups. That machine accepts it locally, then
- X forwards it to all its neighbors that are interested in at
- X least one of the newsgroups of the message. (Site A deems
- X site B to be ``interested'' in a newsgroup if the
- X newsgroup matches the pattern on the arc from A to B.
- X This pattern is stored in a file on the A machine.) The
- X sites receiving the incoming article examine it to make
- X sure they really want the article, accept it locally, and
- X then in turn forward the article to all their interested
- _____
- X neighbors. This process continues until the entire
- X network has seen the article.
- X
- X An important part of the algorithm is the prevention of
- X loops. The above process would cause a message to loop
- X along a cycle forever. In particular, when site A sends
- X an article to site B, site B will send it back to site A,
- X which will send it to site B, and so on. One solution to
- X this is the history mechanism. Each site keeps track of
- X all articles it has seen (by their message ID) and
- X whenever an article comes in that it has already seen, the
- X incoming article is discarded immediately. This solution
- X is sufficient to prevent loops, but additional
- X optimizations can be made to avoid sending articles to
- X sites that will simply throw them away.
- X
- X One optimization is that an article should never be sent
- X to a machine listed in the Path line of the header. When
- X a machine name is in the Path line, the message is known
- X to have passed through the machine. Another optimization
- X is that, if the article originated on site A, then site A
- X has already seen the article. (Origination can be
- X determined by the Posting-Version line.)
- X
- X Thus, if an article is posted to newsgroup ``net.misc'',
- X it will match the pattern ``net.all'' (where ``all'' is a
- X metasymbol that matches any string), and will be forwarded
- X to all sites that subscribe to net.all (as determined by
- X what their neighbors send them). These sites make up the
- X ``net'' subnetwork. An article posted to ``btl.general''
- X will reach all sites receiving ``btl.all'', but will not
- X reach sites that do not get ``btl.all''. In effect, the
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X - 19 -
- X
- X
- X
- X articles reaches the ``btl'' subnetwork. An article
- X posted to newsgroups ``net.micro,btl.general'' will reach
- X all sites subscribing to either of the two classes.
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X
- X============
- X
- XFrom schein Thu Jun 9 14:36:35 1988 remote from cbmvax
- XReceived: by cbmvax.UUCP (1.2/UUCP-Project/Commodore 12/21/87))
- X id AA14116; Thu, 9 Jun 88 14:36:35 edt
- XDate: Thu, 9 Jun 88 14:36:35 edt
- XFrom: cbmvax!schein (Dan Schein CATS)
- XMessage-Id: <8806091836.AA14116@cbmvax.UUCP>
- XTo: heimat!sysop
- XSubject: How to UseNet
- X
- X
- X How to Use USENET Effectively
- X
- X
- X Matt Bishop
- X Research Institute for Advanced Computer Science
- X Mail Stop 230-5
- X NASA Ames Research Center
- X
- X Moffett Field, CA 94035
- X
- X
- X
- X 1. Introduction
- X
- X USENET is a worldwide bulletin board system in which
- X thousands of computers pass articles back and forth. Of necessi-
- X ty, customs have sprung up enabling very diverse people and
- X groups to communicate peaceably and effectively using USENET.
- X These customs are for the most part written, but are scattered
- X over several documents that can be difficult to find; in any
- X case, even if a new user can find all the documents, he most
- X likely will have neither the time nor the inclination to read
- X them all. This document is intended to collect all these conven-
- X tions into one place, thereby making it easy for new users to
- X learn about the world of USENET. (Old-timers, too, will benefit
- X from reading this.)
- X
- X You should read this document and understand it thoroughly
- X before you even think about posting anything. If you have ques-
- X tions, please ask your USENET administrator (who can usually be
- X reached by sending mail to usenet) or a more knowledgeable USENET
- X user. Believe me, you will save yourself a lot of grief.
- X
- X The mechanics of posting an article to USENET are explained
- END_OF_FILE
- if test 48305 -ne `wc -c <'man/Standards.aa'`; then
- echo shar: \"'man/Standards.aa'\" unpacked with wrong size!
- fi
- # end of 'man/Standards.aa'
- fi
- echo shar: End of archive 15 \(of 16\).
- cp /dev/null ark15isdone
- MISSING=""
- for I in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ; do
- if test ! -f ark${I}isdone ; then
- MISSING="${MISSING} ${I}"
- fi
- done
- if test "${MISSING}" = "" ; then
- echo You have unpacked all 16 archives.
- rm -f ark[1-9]isdone ark[1-9][0-9]isdone
- else
- echo You still need to unpack the following archives:
- echo " " ${MISSING}
- fi
- ## End of shell archive.
- exit 0
- --
- Submissions to comp.sources.amiga and comp.binaries.amiga should be sent to:
- amiga@cs.odu.edu
- or amiga@xanth.cs.odu.edu ( obsolescent mailers may need this address )
- or ...!uunet!xanth!amiga ( very obsolescent mailers need this address )
-
- Comments, questions, and suggestions should be addressed to ``amiga-request''
- (please only use ``amiga'' for actual submissions) at the above addresses.
-